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= (54) Title: SYSTEM AND METHOD FOR SELECTING A SERVICE PROVIDER 




® (57) Abstract: The invention provides a selection system and method to facilitate the provision of services on a computer network 
to prospective service users. In a preferred embodiment a computerised method of enabling a buyer to select a service provider 

— * for performing a service is described. The method includes processing a service enquiry for a particular service, and retrieving 

£2 historical cost or invoicing data associated with said service in respect of a plurality of service providers in response to the enquiry. 
The historical cost data is processed to arrive at comparable cost data for enabling the selection of a service provider to perform the 

Q particular service. Cost or invoicing data relating to the provision of the particular service by the selected service provider is then 
captured, and the historical cost data is updated by incorporating the captured cost data. In this way, separate quoting or tendering is 

^ eliminated and job selection is effectively based on historical invoicing data. r*r-r\*m» « ^ _ 
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SYSTEM AND METHOD FOR SELECTING A SERVICE PROVIDER 
Field of the invention 

The present invention relates to a system and method for allowing a service user to quantify and compare the 
desirability of competing service providers, and to select a service provider to perform a particular service. 

5 Background of the Invention 

Potential purchasers of goods are often able to choose the product most appropriate to their needs by examining the 
product and assessing the quality of its construction and its suitability to the purchaser's needs. Usually, the price of the goods is 
known and therefore the purchaser may be able to base their purchase decision on a cost/benefit analysis of the product 

In contrast to goods, potential users of a service generally do not have the same level of information available to them 
10 on which to base their selection of a service provider. Therefore the process of ascertaining which service provider is the most 
appropriate, efficient and/or cost effective provider to perform a job can be a complex, time consuming and inexact process. 

Traditionally services have been procured using a tendering process. Participating service providers prepare a proposal 
in response to a tender request made by the service user. The service user can then compare the proposals and select the most 
desirable service provider. 

15 As the need for the service user to perform research into the potential service providers is reduced, the service users 

perceive that there is a time and cost advantage to them in using a tender system. However, the perceived advantages of a tender 
system may not be borne out in actuality for a number of reasons. For example, the tender documents from all of the potential 
suppliers may not be readily comparable due to different terminology, methodology or charging practices of the suppliers, and 
hence additional effort is required to perform (he comparison between the various tender responses received Furthermore, in 

20 situations where a service user (or group of service users) have a large number of low cost jobs to be performed, the time and 
effort expended in compiling, reviewing and comparing tenders may make using a tendering process both slow and uneconomical 
for both buyers and sellers. 

In particular, a tendering system may also become disadvantageous for the suppliers when the cost and effort required to 
submit a tender for a job outweighs the profit of peiforming the job. 

25 in order to address the identified disadvantages of prior art service procurement methods, International patent 

application PCT/AU0 1/00660 to the applicant proposes a system and method for fecilitating the selection of a service provider to 
perform a job. The system described therein uses the current rates charged by each service provider to estimate a cost 
effectiveness ranking for each service provider and allows the buyer to select a service provider based on this information. 

It has been found by the present inventors that the system disclosed in International application PCT/AU0 1/00660 has a 

30 number of disadvantages. A system of this type is time consuming for sellers, as the sellers are required to enter rates or quotes 
into the system regularly to obtain work. The system described therein is also susceptible to manipulation by service providers 
who wish to win additional work. This can be done by a service provider inputting lower than market value rates into the system 
in order to obtain a more favourable cost effectiveness ranking. However, when it comes to the provision of the service the final 
invoiced cost of the job to the buyer may include the cost of extra items or service time in addition to that requested, surcharges 

35 etc. In such cases the predicted cost effectiveness of the service provider is not accurate. 
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Summary of the Invention 

According to a first aspect the present invention provides a computerised method of enabling a buyer to select a service 
provider for performing a service; said method including the steps of: 

(a) processing a service enquiry for a particular service; 
5 (b) retrieving historical cost data associated with said service in respect of a plurality of service providers in response to 

said enquiry; 

(c) processing said historical cost data to arrive at comparable cost data in respect of said service providers for enabling 
the selection of a service provider to perform the particular service; 

(d) capturing cost data relating to the provision of the particular service by the selected service provider, and 
1 0 (e) updating the historical cost data by incorporating said captured cost data. 

Conveniently, the method includes the additional steps of repeating steps (a) to (e) to enable a buyer to select a service 
provider for the provision of subsequent services with the aid of regularly updated cost data. 

Advantageously, the method includes the step of compiling an historical cost dataset including historical cost data 
associated with the provision of at least one similar previous service by each service provider. 
1 5 Typically, the service enquiry includes a plurality of service components and the historical cost data includes historical 

cost data for a plurality of comparable service components, and step (c) includes the sub-step of: 

processing said historical cost data to arrive at cost data for each of said service components. 

Hie cost data captured in step (d) may include cost data for each of the service components included in the service 

enquiry. 

20 The service components may include cost per unit of time and distance, in combination with units of time and distance. 

Preferably, the method includes the steps of: 

(f) retrieving historical quality data associated with said service in respect of a plurality of service providers in response 
to said enquiry; and 

(g) processing said historical quality data to arrive at comparable quality data in respect of said service providers to 
25 enable the selection of a service provider to perform the particular service. 

The method may include the further steps of: 

(h) capturing quality data relating to the provision of the particular service by the selected service provider, and 

(i) updating the historical quality data to reflect said captured quality data. 

Steps (f) to © are typically repeated to assist a buyer to select a service provider for the provision of subsequent 
3 0 services with the aid of regularly updated quality data. 

The method may include the step of compiling an historical quality dataset including historical quality data associated 
with the provision of at least one previous service by each service provider. 
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Hie historical quality data may include historical quality data for a plurality of performance attributes, and the service 
request enquiry may include a plurality of comparable performance attribute weightings reflecting the relative importance of at 
least two of me performance attributes to the buyer. 

Step (g) typically includes (he sub-step of processing said historical quality data in respect of each of the performance 
attributes to anive at comparable performance data in respect of each performance attribute, and combining said comparable 
performance data according to performance attribute weightings contained in the service enquiry for each service provider, to 
generate said comparable quality data. 

The method may include the step of quantifying the selected quality factors using any derived scale, weighting such 
factors according to their relative importance, normalising the factors and combining mem with the similarly normalised historical 
cost factors, in combination with an additional weighting factor. 

By the term "quality data" is meant any non price-related factor which may influence the decision of the buyer to select 
a particular seller. Typical examples include effectiveness and result factora, level of competence comprehensiveness, turn- 
around or implementation time, completeness, value added components, safety factors, and the like. 

The comparable cost data and comparable quality data in respect of each of the service provideis may be combined to 
derive a comparable performance index for each service provider for enabling the selection of a service provider to perform the 
particular service, with the combination of the comparable cost data and comparable quality data being arranged in accordance 
with weightings reflecting the relative importance of the comparable cost data and comparable quality data to the buyer. 

The historical cost data can preferably include corresponding historical service enquiry data, and the step of processing 
said historical cost data can include processing said related service enquiry data to arrive at comparable cost data. 

Preferably the method includes the steps of capturing service enquiry data associated with the captured cost data, and 
updating the historical cost data by incorporating said captured service enquiry data. 

According to a second aspect of the invention there is provided a computerised method of enabling a buyer to select a 
service provider for performing a service, said method including the steps o£ 

(a) compiling historical cost and quality datasets including historical cost and quality data associated with the provision 
of at least one previous service by each service provider. 

(b) receiving and processing a service enquiry from the buyer for a particular service; 

(c) retrieving historical cost and quality data associated with said service in respect of a plurality of service providers in 
response to said enquiry; and 

(d) processing said historical cost and quality data to arrive at comparable cost' and quality data in respect of said service 
providers for enabling the selection of a service provider to perform the particular service. 

The method preferably includes the subsequent steps oft 

(e) capturing cost and quality data relating to the provision of the particular service by the selected service provider, 

(f) updating the historical cost and quality data to incorporate said captured cost and quality data, and repeating steps 
(b) to (f) to enable a buyer to select a service provider for the provision of subsequent services. 
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The method may include the steps of formatting the service enquiry into a plurality of service components, and 
formatting the historical cost and quality data into a plurality of comparable service components, with step (d) including the sub- 
step of. 

processing said historical cost and quality data to arrive at cost and quality data for each of said components. 
5 The invention extends to a computer-readable medium having stored thereon executable instructions for causing a 

computer to perform a method of enabling a buyer to select a service provider for performing a service; said method including the 
steps of: 

(a) processing a service enquiry for a particular service; 

(b) retrieving historical cost data associated with said service in respect of a plurality of service providers in response to 
10 said enquiry; 

(c) processing said historical cost data to arrive at comparable cost data in respect of said service providers for enabling 
the selection of a service provider to perform (he particular service; 

(d) capturing cost data relating to the provision of the particular service by the selected service provider, and 

(e) updating the historical cost data by incorporating said captured cost data 

1 5 Preferably, the computer-readable medium has further executable instructions for causing a computer to repeat steps (a) 

to (e) to enable a buyer to select a service provider for the provision of subsequent services with the aid of regularly updated cost 
data 

The invention also provides a computer operating under the control of the computer readable medium. 

The executable instructions may be in web-compatible Mark-up language such as HTML, XML, or XML/EDI. 
20 According to a still further aspect of the invention there is provided a computer system to enable a buyer to select a 

service provider for performing a service; said system including: 

enquiry processing means configured to receive and process a service enquiry for a particular service from the buyer ; 

a database configured to store historical cost data associated with said service in respect of a plurality of service 
providers; 

25 a processor adapted to retrieve and process said historical cost data from said database in response to said query to 

arrive at comparable cost data in respect of said service providers for enabling the buyer to select a service provider, on the basis 
of said comparable cost data, to perform the particular service. 

Preferably, the computer system includes data capture means configured to capture cost data relating to the provision of 
the particular service by the selected service provider, and updating means to update the historical cost data on the database with 
30 said captured cost data 

Typically, the enquiry processing means is configured to retrieve historical quality data associated with said service in 
respect of a plurality of service providers in response to said enquiry, and the processing means is configured to generate 
comparable quality data from said historical quality data in respect of said service providers. 
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The historical quality data typically includes historical quality data for a plurality of performance attributes, and the 
service request enquiry includes a plurality of comparable performance attribute weightings reflecting the importance of each of 
the performance attributes to the buyer. 

The processor may be configured to process said historical quality data in respect of each of the performance attributes 
5 to arrive at comparable performance data in respect of each perfoimance attribute, and to combine the comparable performance 
data according to the performance attribute weightings included in the service enquiry for each service provider, to generate said 
comparable quality data. 

The processor may be configured to derive a comparable performance index for each service provider by combining the 
comparable cost data and comparable quality data in respect of each of the service providers with the combination of the 
10 comparable cost data and comparable quality data being is performed in accordance with weightings reflecting the relative 
importance of the comparable cost data and comparable quality data to the buyer. 

The invention further provides a computer system to enable a buyer to select a service provider for performing a service; ( 
said system including: 

a database configured to store a first dataset including a plurality of service providers, a plurality of associated services 
15 and a plurality of associated historical costs; 

a processor in communication with said database, wherein said processor is configured to receive historical cost data 
associated with each service provider and to generate comparative cost data for each service provider according to a 
predetermined algorithm; and 

communication means configured to communicate said comparative cost data to said buyer to enable the buyer to select 
20 a service provider. 

Preferably, the predetermined algorithm includes weighting means configured to weight a plurality of received historical 
cost data according to the respective associated service of the historical cost data, and to generate the comparative cost data in 
accordance with said weighting. 

Conveniently, the processor includes weighting optimisation means adapted to optimise the weightings applied by the 
25 weighting means to the received historical cost data, with the weighting optimisation means utilising an algorithm which has the ( 
effect of weighting the most recent data more heavily. 

The computer system may further include data capture means configured to capture cost data associated with a current 
service provided by a service provider, and updating means adapted to update said first data set to include said cost data 
associated with the current service provided by a service provider. 
30 Typically, the historical cost data includes a plurality of associated service components and associated historical cost 

component data; and the processor is configured to generate comparative cost data in respect of each service component for each 
service provider. 

Conveniently, the data storage means is configured to store a second dataset including a plurality of service providers, a 
plurality of associated services and a plurality of associated historical quality data, and said processor means is configured to 
35 additionally receive historical quality data associated with each service provider and generate comparative quality data for each 
service provider according to a predetermined algorithm; and said communication means is arranged to communicate said 
comparative quality data to the buyer to enable the buyer to select a service provider. 
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Tht comparative quality data may comprise a comparable quality index which can be processed with the comparable 
cost data to yield a comparable desirability index, typically by a process of normalisation. 

The database may be further configured to store historical service enquiry data associated wife the historical cost data, 
and wherein the processor executes instructions to retrieve and process said historical cost data in conjunction with said related 
5 service enquiry data to arrive at said comparable cost data. 

The data capture component can be configured to capture service enquiry data associated with the captured cost data, 
with the updating means being arranged to update the historical cost data on the database with said captured cost and service 
enquiry data. 

The present invention is based on the insight that an efficient marketplace can be encouraged if suppliers of services 
10 and/or goods know that their future work-flow is deteirnmed by a systematic comparison of their historical costs and historical 
quality. Thus the present system and method encourages sellers of goods and/or services to provide a high quality of products and 
services at competitive rates in order to increase their likelihood of obtaining business in the future. 

In the specification and claims the term "services" should be understood to extend to services feat include the provision 
of associated goods or spare parts as a sub-component of the service. 

15 It will be understood that the invention disclosed and defined herein extends to all alternative combinations of two or 

more of the individual features mentioned or evident from the text or drawings. All of these different combinations constitute 
various alternative aspects of the invention. 

Brief description of the drawings 

Notwithstanding any other forms which may fall within the scope of the present invention, preferred forms of the 
20 invention will now be described, by way of example only, with reference to the accompanying drawings in which: 

Figure 1 shows a flow-chart illustrating a method according to a first embodiment of the present invention; 

Figure 2 shows a portion of the historical cost data used for the production of the spreadsheet shown in Figure 3; 

Figure 3 shows a spreadsheet configured to calculate comparable cost effectiveness rankings of service providers 
according to the first embodiment; 

25 Figure 4 shows a sample database of historical data request for surveillance investigations for a hypothetical buyer in 

connection with a second embodiment of the present invention; 

Figure 5 shows a spreadsheet of a mean historical responses for three sellers for each question tabulated in the database 
of Figure 4; and 

Figure 6 shows an exemplary system for assisting a buyer to select a service provider, and 

30 Figures 7A to 7E show a schematic representation of a relational database used in connection with a preferred 

embodiment of the present invention. 

Detailed description of the embodiments 

In broad concept the present invention provides a system which can be used by an individual or organisation wishing to 
select a supplier from a group of suppliers to perform a service, with or without the provision of associated goods. The preferred 
35 embodiment of the present invention provides a method and system for achieving an efficient marketplace between a group of 
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sellers and at least one buyer, where the buyer or buyers repeatedly purchase products or services from the sellers. The preferred 
embodiment may advantageously be applied to situations where a high number of transactions between the buyer and the sellers 
occur, thus providing a large amount of historical data on which to base predictions of future cost, quality, timeliness or other 
desired performance criteria. However the present invention should not be construed to be limited to a market of this type. 
5 Preferably in using the system and method as described the service providers are aware that the attributes of their 

services (in particular price) will be compared with those of other service providers, thereby fostering competition within the 
marketplace. Accordingly the system and method described may provide means for trading in services of relatively low value 
which has the benefits of a tender system without requiring service providers to tender on a job-by-job basis 

In the present embodiment the system is particularly suited for selecting services and/or goods supplied with an 

10 associated service, which can be readily broken down into a number of identifiable and comparable service components or 
elements. Typically service elements will be tasks or features of the service for which service providers can allocate a discrete fee, 
and which the procurer of the service can readily use to define the scope or quality of the service desired. 

The first step in using the system according to this embodiment is initialisation. The initialisation process begins by 
defining the elements of the service and a set of performance criteria which describe them. The service performance criteria can 

15 be used by a service user to describe a job they need performed, and by the service provider to describe attributes of the services 
which they perform. 

The performance criteria describing the services can include attributes relating, inter alia, to: 

- the nature of the services; 

- specific attributes of the services; and 

20 m cost of the service, or the cost of specific readily identifiable elements or components of the service; 

. the quality or type of equipment and/or resources required to perform a service; 

- the qualifications or association memberships desired by people performing a service; 

- other attributes of the service provider performing the job, which can affect the kind, quality or style of service 
performed, such as the length of time the supplier has been in business etc; and 

25 - historical information relating to the performance of past services which may be indicative of the level of service 

provided, such as the percentage of past jobs completed within a set deadline, and the satisfaction of previous service users with 
the service offered. 

As described above, the system and method of the preferred embodiment of PCT/AU0 1/00660 primarily uses the 
current rates charged by each service provider to estimate a cost effectiveness ranking for each service provider, taking certain of 
30 the above performance criteria into consideration, and allows the buyer to select a service provider based on this information. 

The inventors of the present invention have surprisingly discovered that accurate and robust estimates of expected costs 
can be derived by effectively ignoring the current or quoted rates charged for services and/or associated goods by sellers. The 
present embodiment accordingly uses historical cost data, which represent the actual amounts invoiced for a group of previous 
transactions and the description of the services and/or goods requested or supplied in each of the previous transactions to estimate 
35 and to drive future costs for similar or identical services. The provision of services can clearly include the provision of associated 
goods and disbursements. 
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By making the selection process known to the supplier, the supplier is encouraged to charge each customer as 
competitively as possible in the knowledge that their current invoicing directly affects their future work-flow. For the purchasers a 
marketplace operating on this principle is preferable as it encourages competition and lowers prices. Furthermore the present 
system is clearly preferable to receiving tenders or quotes, which are time consuming to prepare and to review and are susceptible 
5 to manipulation by suppliers. 

An embodiment of the present invention will now be described in the context of the provision of insurance investigation 
services, more particularly in the context of the provision of 20 hours of surveillance of an insurance claimant As will be 
appreciated by those skilled in the art the present invention is not limited to the provision of investigation services, but may be 
applied to the supply of services without limit The services may or may not include a travel or delivery component. 
10 Figure 1 outlines the steps in the present embodiment As described above, in order to perform the method, the services 

and/or associated goods being traded in the marketplace must be defined. This is done in step 1 of the flow-chart 

The services and/or associated goods are defined by a set of elements that make up the services and/or associated goods 
and optionally a set of qualitative performance attributes. The elements of the services and/or associated goods can be used by a 
buyer to describe a product or service they need. Each of the sellers or service providers in the marketplace are required to split 
15 their invoices for each job into their charges for each element, to enable historical data to be readily assimilated and ultimately 
compared for each seller. 

The qualitative performance attributes describe factors other than price which can affect the quality or kind of services 
and/or associated goods supplied by each seller, such as the quality or type of equipment and/or resources used to perform a 
service, or the qualifications or association memberships possessed by people performing the service. Historical quality or 
20 timeliness measures, such as the percentage of past jobs completed within a set deadline; and the level of satisfaction of previous, 
service users with the supplier can also be used as qualitative performance attributes. 

In the present example, where the service requested is an investigation service, two elements are used. The first element 
is travel, and the second element is an hourly rate for performing surveillance. 

Once the services and/or associated goods being traded are defined in terms of their elements, the buyer can place a 
25 request for services and/or associated goods, in step 2. The buyer's request is set out in terms of the quantity of each element 
which they desire. The buyer can also specify relative weightings for each of the qualitative performance criteria if they wish to be 
presented with a comparable quality estimate for each of the service providers. 

Optionally an importance weighting can be given to cost and quality criteria to allow the buyer to compare criteria of 
different types to one another. For example, if quality is twice as important to a buyer as price, then a final comparable desirability 
30 index can be generated in which the cost raring and quality ratings are weighted such that two-thirds of the final comparable 
indices for each seller are made up from a quality rating and one third from a cost-effectiveness rating. 

Alternatively the comparable desirability index can be generated by using the quality rating as a multiplier which scales 
the comparable cost data For example, each supplier's quality rating can be scaled into a multiplier between 1 and 1.5, with 1 
being the highest quality and 1.5 the lowest quality. The remaining suppliers' quality multipliers can be scaled proportionally 
35 between these endpoints. The desirability index can then be calculated by multiplying the comparable cost estimate by the quality 
multiplier to generate a desirability index. Clearly the lower the desirability rating the more desirable the service provider is. 

In step 3 the market-place software provides the buyer with a rating for each seller, reflecting their ability to fulfil the 
request Typically this will be a cost effectiveness rating which is normalised to 1. A rating of "1" means a seller is of average 
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price for the job, and a rating of 1.5 means that the seller is 50% more expensive than average. As will be appreciated by those 
skilled in the art other methods of presenting results enabling buyers to compare the relative cost and/or quality of the service 
providers can be used For example, rather than normalising the cost estimates such that the average supplier is given a value of 1, 
the lowest cost supplier can be given a rating of 1, with more expensive suppliers being rated grater than 1 eg. 1.1 can be given to 
5 a supplier who is 1 0% more expensive than the cheapest supplier. 

As described above it has been discovered that accurate and robust cost effectiveness ratings can be based primarily, or 
solely, on historical data extracted from previous invoices issued by a seller. 

A normalised quality rating based on the qualitative performance attributes such as service quality, or timeliness, can 
also be derived from historical data, that reflects, inter alia, the satisfaction level of customers previously dealt with by the seller. 
10 The cost and quality ratings can then be combined according to the buyer's weightings, if it is desired to determine a final 
comparable rating for each seller. 

In step 4 the buyer selects a seller, and in step 5 the seller supplies the services and/or associated goods requested to the 
buyer. The seller then, in step 6, invoices the buyer in a predetermined format for the supply of the services and/or associated 
goods. 

15 Finally, in step 7, the seller's invoiced amount for the current request is added to the data set of historical data which 

can be used in for future predictions. Hie buyer can also rate one or more of the seller's qualities in performing the job, such as 
timeliness, for addition to the historical quality data set 

Figure 6 shows an exemplary system for implementing the present invention. The system 1000 includes one or more 
service providers such as service provider 1010 and service providers 1010.2 to 1010.N and one or more buyers 1020 to 1020.M 
20 connected to the selection system 1030 via a communications network 1051. The selection system 1030 is connected to the 
communication network by an input/output port or other communications means 1040. Hie selection system 1030 includes four 
main subsystems, namely: 

• an enquiry processing subsystem 1 050; 

• a data capture and invoicing subsystem 1060; 
25 • a database 1 070; and 

• a data processing subsystem 1 080. 

The enquiry processing subsystem 1050 is adapted to receive a job request from a buyer, and to pass the request to the 
data processing subsystem 1080 in a form suitable for further processing. The enquiry processing subsystem 1050 splits an 
incoming request eg request 1100 into its request components or elements 1100A and 1100B. If the buyer has additionally 
30 specified weightings, ranking the importance of each of the elements of the request the enquiry processing subsystem 1050 
extracts the weightings 1110 from the request 1100 and sends them to the weighting section 1090 of the processor subsystem 
1080. In an alternative embodiment the request weightings 1 110 can be forwarded to the data processing subsystem 1080 and 
grouped with their corresponding request element data eg 1 100A or 1 100B. The enquiry processing subsystem also passes request 
data, which is to be stored in the database 1070 as historical data, to the updating means 1064. 

35 Upon receipt of a service request 1100 from the enquiry processing subsystem 1050 which is split into its elements 

1 100A and 1100B, the processing subsystem 1080 interrogates database 1070 to extract historical data relating to each element 
1100A and 1100B of the service request 1100. The data processing subsystem 1080 uses the retrieved historical information 
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relating to each request element, for all prospective service providers, to generate a comparable performance ranking for each of 
the service providers. The comparable performance ranking for each service provider is men sent to the buyer via the 
communications network to allow the buyer to select a service provider. 

The data processing subsystem 1180 includes the weighting section 1 090 which allows weightings to be extracted and 
5 applied during the calculation of the comparable performance data. Firstly, the relative importance of each element of a request 
may be weighted in accordance with request weightings 1110 included in the buyer's request 1100. Alternatively, a 
predetermined weighting scheme can be set up for each buyer and stored either in the weighting section to allow a predetermined 
weighting routine to be used for all job requests issued by a particular buyer. Weightings can also be applied by the weighting 
section 1 090 to the historical data received from database, for example so that more account is taken of the most recent historical 
10 data, and less cognisance is taken of older historical data, when generating the comparative data with the data processing 
subsystem 1080. The weighting section 1090 can also include a weighting optimisation algorithm 1095 having weighting 
variables which can be used to optimise the weightings given to the historical data when calculating the comparable performance 
data. If it is determined that the historical data relating to the five most recent jobs performed by each service provider is to be 
used by the data processing subsystem 1080 to calculate the comparative data, the weighting optimisation algorithm 1095 can be 
15 used to impose this condition on the calculations of the processing subsystem 1080. The weighting optimisation algorithm can 
also utilise feedback from the selected service provider 1010, which is received by the data capture means to generate optimal 
weightings for historical data. A process for optimising weightings is described below. 

When the comparative data is generated in the data processing subsystem 1080 the data is communicated by the 
communication means 1040 and the communications network 1051 to the buyer. The buyer can then select a service provider to 
20 perform the job. The process of retaining the selected service provider to perform a job is performed by the provider retention 
system 1200. The provider retention system 1200 is configured to receive a retention confirmation from the buyer indicating the 
buyer's selected service provider. The provider retention system 1200 then generates and sends a work order, and an email 
confirmation to the selected provider, indicating that he or she has been selected to perform the buyer's requested job. 

Once the service has been performed the selected provider 1010 will issue an invoice to the buyer 1020. In this 
25 embodiment the invoice is generated by the invoicing system 1063 of the data capture and invoicing subsystem 1060. The 
selected provider indicates to the system the amounts to be charged to the buyer for each element of the job performed, by 
answering a series of invoicing questions. This generates an invoice in an agreed format, including appropriate breakdowns for 
rates, times, distances and the like that correspond with the various request elements. In the preferred embodiment the service 
provider's invoice is transmitted to the buyer 1020 via the invoicing system 1063. The invoicing system 1063 also sends the 
30 service providers answers to the invoicing questions relating to the cost charged for each element of the service to the answers 
table 1707 of the database 1070 via the updating port 1064. 

Thus the system may be viewed as including an automatic feedback system whereby every time a service provider 
performs a job the service provider's invoice for that job is broken down into a cost for each requested element and this 
information is stored in the database 1070. This feature of automatic updating of the database in combination with the use of 
35 weightings allows the system to emphasise the most recently performed jobs in a predetermined way (using the weightings 
optimisation algorithm 1095), such that the most recent invoice, or a weighted combination of the most recent invoices issued by 
each service provider will be effectively become a tender for the next requested job. 

The data capture and invoicing subsystem 1060 also includes a qualitative feedback system 1065 which allows both the 
buyer 1020 and selected provider 1010 to input data relating to the quality of the service provided. The qualitative feedback 
40 system 1065 gathers data from bom the buyer 1020 and selected provider 1010 relating to the qualitative aspects of the service 
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being provided. For example the service provider 1010 can be asked to specify the time at which the job was begun and when it 
was completed and such data can then be used to rank the timeliness of the service provider for future jobs. The buyer 1020 can 
be asked to rate the quality of the service provided according to a variety of qualitative criteria of the type described former on in 
the specification. The qualitative data thus collected by the qualitative feedback system 1065 is stored as an answer 1707 to its 
5 associated question 1 708 in the database 1 070, via the updating means 1 064. 

As mentioned above, prior to using the selection system, it must be initialised by the compilation of a database of 
historical cost and quality information. This is performed by the compilation component 1066. The compilation component 1066 
effectively allows a series of data to be uploaded into the database via the updating port 1064. 

As will be appreciated by those skilled in the art, the various subsystems may be embodied either as hardware or 
10 software components of the system. For example, a dedicated processor could be used for each of the data capture, enquiry 
processing subsystem 1050, and data processing subsystems 1090, or alternatively a single micro-processor may be used to 
perform each function of these subsystems with the function of each subsystem being defined in various sub-routines of the a 
software package running on that micro-processor. 

In the preferred embodiment the communications network 1051 is the internet However, the communications network 
1 5 can, in general, be any type of wireless or wired computer network that allows the service providers and buyers to exchange data 
with the selection system 1030. In large organisations which have a number of users (buyers) it may be convenient to have an in- 
house selection system, in which case the buyers 9 terminals and selection system will be located as part of the company intranet 
or LAN, and the selected service providers may be connected to it by the Internet, WAN, or other external network. 

Figure 2 shows part of a data set 200 containing historical data for two of three investigation companies. The data 
20 represents data extracted from the database of figures 7A to 7E. Each row 204 represents one job requested by a buyer, and 
performed by the company, with the most recent request appearing first The data contained in each of the rows 204 can 
alternatively be viewed as invoices rendered by the seller. 

Hie first column 210 of the data set designates the company issuing the invoice, and is extracted from the sellers table 
1701 of database 1070, and the second column 215 represents the distance travelled by the company when performing an 

25 investigation this data is stored as an answer to a question in table 1707 of database 1 070. The distance travelled in each case may 
not be equal to the distance invoiced by the service provider for the job, rather it is calculated by the marketplace software. Hie 
distance is determined by calculating the distance between the service provider nearest operating location and the location at 
which the surveillance job is performed. Thus in essence this is a theoretical distance requested by the buyer and may not 
represent the actual distance travelled by the service provider in perfonxiing the job. The next column 220 contains the amount, in 

30 dollars, charged by the service provider for the travel performed in each job this data is also stored as an answer to a question in 
table 1707 of database 1070. In this case the answer is the answer to a question asked of the supplier when an invoice is 
generated. Column 225 contains the number of units of surveillance requested by the buyer in each job, as with column 215 this 
data is stored as an answer to a question in table 1707 of database 1070. Again, this number is not representative of the number of 
hours billed by the company in each job but is the actual number of hours requested by the buyer. Final column 230 contains the 

35 actual amount charged by the company for performing surveillance in each job. Hus data is an answer provided by the supplier 
when creating an invoice and is stored in the answers table 1707 of database 1070. If additional services are requested by the 
buyer, additional columns of Mormation may be contained in the data set. For example, if a cost is charged for writing a report, 
or providing photographs to the buyer, or administrative charges are levied then the invoice can be broken down into additional 
elements, and data collected for each of these extra components. Again these additional service components would be represented 

40 as one column representing the number of units of each additional service requested by the buyer and the total charged for the 
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item in each particular job. Alternatively the administrative or photographic costs can be added into the surveillance costs to 
provide a consolidated element. 

Figure 3 shows the results of the various calculations performed by the marketplace software. Tne first row of the 
spreadsheet 300 sets out the request input into the system by the buyer. In this case the request is for 20 hours of surveillance 
5 performed at a particular location. Hiis is represented in row 3 10 by the travel request in cell 315. Tne travel request is of variable 
length depending on which company is engaged as shown in cell 315. Cell 317 represents a request for 20 units (each unit being 
an hour) of surveillance. Each component of the service can be weighted to reflect the importance of it to the buyer. As all of the 
values in this request are monetary values and cost effectiveness is the desired suitability measure the travel cost is weighted 
equally with the surveillance cost. This is represented by the value 1 being placed in cells 316 and 318. Cell 319 represents the 
10 aggregate value of all of the weightings of the components on the service requested by the buyer. 

The service request in spreadsheet 300 is also displayed in a form which includes the travel distance required for each of 
the service providers. In this instance the three service providers, LKA, M&A, and Lou (321, 322 and 323 respectively) each have 
to travel a different distance to perform the job. It can be seen that by looking at the values in row 321 LKA must travel 1 8 km to 
perform the job, M&A must travel 20km (cell 322), and Lou must travel 22km (cell 322). The other values contained in these 
1 5 rows do not vary between the service providers, and are thus identical to that shown in the request row 3 1 0. 

Rows 330, 340 and 350 of the spreadsheet 300 show a series of calculated values representing the costs historically 
charged by each of the service providers for the performance of surveillance jobs in the past For each of the service providers the 
value contained in column 335 represents the average travel distance requested in past jobs. The value in column 336 represents 
the average travel cost which each service provider has invoiced in the past These values are derived from the actual values 

20 invoiced by the service provider. The values in column 337 are derived by dividing the average invoiced travel cost by the 
average requested travel distance for each service provider, to determine an average travel cost per requested kilometre of travel. 
It can be seen that in the past LKA on average has been requested to travel 1 9. 1 8km for each job which they have performed and 
on average has invoiced their client $218.18 for travel giving an average cost per requested kilometre of $11.37. From row 340 
can be seen that M&A*s average travel request is 18km and their average travel cost is $200 giving rise to an average cost per 

25 requested kilometre of $ 1 1 .1 1 . Lou on average has been requested to travel 21 .36km per job and has charged $227.27 on average 
per invoice for the travel component in previous jobs. Thus Lou's average travel cost is $ 1 0.64 per requested kilometre of travel. 

In the present embodiment the cost per unit for each component of the invoice is calculated from the amounts invoiced 
on previous jobs, and the number of units requested by the buyer in previous jobs. This is distinct from using the number of units 
of service delivered by the service provider. Thus, service providers who habitually over-service, by providing more units of a 

30 particular good or service than requested, or who are inefficient and require additional time or travel to perform a job, are shown 
up by the system as being more expensive since the number of units for which they issue an invoice is greater than the requested 
number of units. Ibis ability to take into account and to compare the variable work practices of goods and service providers when 
determining their average historical cost also provides advantages for more efficient or cheaper goods and service providers. An 
example of this can readily be seen in terms of the travel component of a job. If a service provider can perform the service with 

35 less than the predicted travel distance and does not premium" their travel expenses to bring mem into line with expectations, 
their average cost per unit of requested travel will decrease. 

In alternative embodiments, particularly in industries where over-servicing is not a common problem or services tend to 
be provided on an on-going basis, ie service requests are not made for a fixed number of units, the number of units supplied may 
be used to determine the average cost per unit for a particular element of a service. 
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Columns 345, 346 and 347 of rows 330, 340 and 350 show calculations to determine the average cost per requested unit 
for surveillance tasks. This is performed in a similar fashion to the travel cost Column 345 displays the average number of 
surveillance hours requested on previous jobs performed by LKA, M&A and Lou respectively. In this example each of the 
suppliers has on average been requested to perform 20 hours of surveillance per job in the past Column 346 shows the average 
cost invoiced to their clients in respect of the previous jobs performed by each service provider. On average both LKA and M&A 
have charged an average of $800 for 20 hours of surveillance whereas Lou has charged an average of $781.00 for 20 hours of 
surveillance in the past. Column 347 contains the average historical cost per unit of surveillance requested for each of the service 
providers. As can be seen by the value in row 350 in the past Lou has invoiced me lowest cost per requested unit of surveillance 
in the past 

As described as above in relation to travel cost, the cost per requested unit value derived for the surveillance component 
of this job reflects a comparison between the jobs requested in the past and the actual charges invoiced for these previous jobs. 
Thus if one of the service providers commonly suggested to their clients after 20 hours of requested surveillance was performed 
that an additional 10 houis of surveillance was needed to adequately complete the job and an additional amount was invoiced for 
these hours over and above the initial request mis would be reflected as an increased cost per requested unit, rather than as an 
increase in the number of hours requested in a previous job. 

In the present example the calculation of the cost per unit of requested services and/or associated goods has been 
calculated by averaging the invoiced cost for the most recent jobs performed by each service provider. However, other statistical 
methods and analysis can be performed to accurately predict for the invoiced cost per unit requested. For example, a weighted 
average of the value over the previous ten (or any desired sample size) jobs may be used for each service provider. The largest 
weighting can be given to the most recent job, with the weighting tapering off to the lowest weighting for the oldest job. By using 
a weighting system such as this, service providers are encouraged to think carefully when issuing each bill as they know that their 
most recent bill is the most important fector in them securing their next job. 

The number of past jobs which are included in the data set may also be varied to tailor the system to a particular 
application. For example, in some industries where price fluctuates quickly it may be necessary to only use a small sample of past 
jobs for determining cost effectiveness. Furthermore, a different statistical value can be used rather than the average such as the 
median or geometric mean. Certain jobs or sales may even be removed from the sample set used, say the two most expensive and 
two least expensive jobs, or all jobs felling outside two standard deviations from the average. 

In a particularly preferred embodiment, after each job is fulfilled and the invoiced cost recorded, ie. the invoiced cost is 
added to the historical dataset, an optimisation routine can be used to calculate the weighting for historical data which would have 
resulted in the best cost estimate of the newly received invoice. This optimised weighting scheme can then be used to weight the 
updated historical data to estimate the cost effectiveness of the service providers in respect of the subsequent job requests. 

The last group of rows 360 in spreadsheet 300 shows the final cost effectiveness calculations and predictions made by 
the marketplace software. Rows 351, 352 and 353 show the calculated values for LKA, M&A and Lou respectively. The first 
column of values shows an estimated travel cost for each of the companies for the performance of the current requested job. This 
is derived by multiplying the cost per requested unit of travel contained in column 337 by the distance which must be travelled by 
the company to folfil the request made by the buyer. Thus, to derive the entry for LKA in column 361, 11.37 is multiplied by 18 
to arrive at 204.74. Similar calculations are made for M&A and Lou. 

In order to allow the travel costings to be compared to other cost effectiveness or qualitative performance criteria a 
normalised travel cost is derived. The normalised travel costs are derived by dividing the travel cost for each company by the 
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average travel cost for all of the companies. Normalised travel costs for each of the three companies are shown in column 363. A 
company which has a travel cost equal to the average will end up with a normalised travel value of 1, whereas a company who is 
expected to charge 10% above average for this job will receive normalised travel value of 1.1. By performing this calculation it 
can be seen that M&A's normalised travel value is derived by dividing 222.22 by (204.74 + 222.22 + 234.04/3) - 1.01 . 

5 An identical process is performed for estimating the surveillance cost for each service provider in columns 364 to 366. 

In this regard, the values of column 364 are derived by multiplying each company's average cost per surveillance unit (which is 
shown in column 347) by the number of surveillance units requested. It can be seen that both LKA and M&A are expected to 
charge $800 for the surveillance component whereas Lou is expected to charge $781.82. The weighting column 365 is also 
displayed for the surveillance component of the invoice, 

10 Column 366 shows a normalised cost calculation for the surveillance component of the present job for each company. 

Again, mis is calculated for each company by dividing the estimated cost of each company by the average estimated cost for all of 
the companies. It can be seen in this example that LKA and M&A are slightly above average cost, whereas Lou is slightly below 
average cost at 0.98 normalised surveillance value, 

Hie next column 367 shows a total estimated cost for each of the service providers. This is simply calculated by adding 
15 the calculated travel cost to the calculated surveillance cost A normalised total cost is also produced by the marketplace software 
and entered into the cells of column 368. The normalised total cost for each company is produced by dividing each company's 
total cost by the average total cost of all of the companies Thus it can be seen that LKA is predicted to be the most cost effective 
with a predicted cost effectiveness of 1% lower than average, Lou is expected to be of average cost, having a normalised cost 
effectiveness value of 1 and M&A is expected to be 1% more expensive than the average service provider for performing this job. 

20 The last column on this spreadsheet shows a normalised weighted total value for each service provider. The normalised 

weighted total shown in column 369 for each service provider is derived by performing a weighted sum of the normalised values 
of each of the components of the service invoice or other assessment criteria. In this particular example as travel cost and 
surveillance cost of the invoice are both in dollars, they have equal importance and are both weighted as 1 (as shown in cells 316 
and 318 of the spreadsheet 300). Thus for each company the normalised travel value is added to the normalised cost value and 

25 divided by 2, being the total value of the weightings. Thus it can be seen that LKA's normalised weighted total is 0.97, M&A's 
normalised weighted total is 1 .01 and Lou's normalised weighted total is 1 .02. 

The present embodiment also allows the job allocation practices of different buyers using the system to be compared. To 
do so it is advantageous to use a variation on the previously described normalisation process. If one person allocating jobs to 
service providers uses only a small subset of the possible service providers, for example because of geographical limitations or 

30 differences in supplier capabilities, the spread of cost estimates can be relatively small, for example, $900 for the cheapest 
supplier and $1000 for the most expensive. In comparison, a system with users able to select suppliers from a large pool of 
suppliers has a better chance of having supplier with a wider range of historical costs, for example the cheapest estimate for a 
particular job may be as low $700 and the most expensive at $1300. The average cost of each of all suppliers for these jobs may 
both be $1000, but the buyer with the narrow supplier choice would show that they selected the supplier rated at 0.9 ($900 / 

35 $1000), while the buyer with the larger supplier choice would select the supplier at 0.7 ($700 / $1000). A manager comparing the 
buyers would instinctively think that the later buyer is doing a better job of selecting suppliers. 

TTius, instead of comparing suppliers against the average cost supplier, the normalisation can be made against the most 
cost effective supplier. In this example each of the buyers would show up as having selected the supplier rated "1" eg. $700 / 
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$700 «1 and $900 / $900 =1. Thus, each buyer has identified and selected the cheapest supplier, but using the former 
normalisation technique it is not readily possible to compare the decision-making process of me buyers. 

Once the buyer selects a supplier and the supplier fulfils the service request, the invoice from the buyer, which is 
preferably split into the defined service elements, can be added to the historical dataset In a preferred embedment the addition of 
5 invoices to the dataset is automated. In a particularly preferred embodiment the marketplace software is integrated with the billing 
and payment systems of bom the buyers and sellers enabling invoices to be issued and historical cost data to be recorded 
automatically. 

A third embodiment of the present invention will now be described, again in the context of the provision of surveillance 
investigation services. This embodiment of the present invention provides the user with relative cost estimation for each of the 

10 potential sellers based on historical costs, and also provides a number of quality related comparable performance criteria which 
the potential service user may use to pick the most desirable seller. 

Referring first to Figure 4, part of a typical set of data extracted from the database 1070 relating to a number of 
historical requests for surveillance investigations provided by three sellers for a hypothetical buyer is shown. The data is set out in 
spreadsheet form, and includes a transaction identification column 401 (from table 1703 of database 1070) listing 100 sales 

15 transactions, a seller identification column 402 (from table 1701 of database 1070) identifying the seller associated with each 
particular transaction, a question identification column 403 (from table 1708 of database 1070), a number of units column 404 
(from answers table 1707 of database 1070) and a value per unit column 405 (also from an answers table 1707 of database 1070). 

In order to perform the historical cost and quality analysis properly, calculation of the historical costs of the group of 
three sellers must be performed. In the case of a surveillance investigation, this is achieved by breaking down each investigation, 
20 into elements e.g. on a cost per unit of time and distance basis. Each of the historical investigations is accordingly divided into a 
number of "questions" the answers to which are stored as answers (table 1707 of database 1070). Typical examples of such 
questions are listed below: 



Q12 


When was the investigation requested? 


Q13 


Cost per hour of surveillance performed? 


Q14 


Cost per kilometre travelled? 


Q15 


Cost per hour of travelling? 


Q16 


Cost of video tapes recorded? 


Q17 


Administration costs? 


Q18 


Other costs? 


Q19 


Minutes of useful video tape recorded? 


Q20 


Date investigation completed? 


Q21 


% of successful observations on videotape 


Q22 


% of elements of investigation completed satisfactorily 


Q23 


Comprehensiveness of report, as a % 


- Historical C 


Questions 



WO 03/100670 



PCT/AU03/00636 



16 

The question numbers are filled out in the question identification column 403. For example, as is shown at 406, Q13 
corresponds to 22 units and has a value of 38.6. Question 13 deals with the cost per hour of surveillance conducted on the 
particular job. In this case, the particular investigator of seller 1 performed 22 hours of surveillance and charged $38.60 per hour 
ofsurveillanccforatotal cost of $851. Questions 14 and 15 also relate to costs per unit (hours and kilometres respectively), with 
5 the units column 404 detailing the actual number of kilometres and hours travelled. Questions 16-18 refer to other sundry costs, 
and questions 12 and 20 relate to the respective commencement and completion dates of the investigation. The data values given 
as answers to questions 12 and 20 are given in Unix time, namely in seconds elapsed as from 1 January 1972. 

The answers to quality assessment questions 2 1 -23 have been normalised from percentages. By way of example, a value 
of 0.21 is provided at 407, which corresponds to a figure of 21% of successful observations being made on videotape in respect of 

10 the first transaction by seller 1. In the following question 22 shown at 408, the score of 0.92 corresponds to 92% of the 
investigation being completed satisfactorily, and at 409 the Figure 0.94 indicates that the score of 94% was given to the 
comprehensiveness level of the report. It will be understood that, for ease of reference, the quality answers may be given upper 
and lower limits which are ultimately normalised. A permissible answer range may also be provided. In its most basic form, the 
answer range may include "yes" and "no" answers which are allocated a "one" and a "zero" respectively for converting multiple 

15 choice-type answers, intervening answers such as "sometimes", "half the time" and 4l most of the time" may be Normalised" to 
equal, say, 0.25, 0.5 and 0.75 respectively. All of the quality questions are answered and entered on the buyer's side, with 
guidelines being provided to maintain a level of objectivity. 

All of the historical cost data provided in the table of Figure 4 is derived from sellers' historical invoices typically 
furnished by the buyers. The invoices are formatted and broken down in such a way that the data providing "answers" to the 
20 questions can be readily extracted. Ideally, there is a direct correlation between the questions and the per unit cost and number of 
units presented in the invoices. 

The data from each seller may be calculated according to various historical calculation formulae. The simplest formula 
is to take the mean average for each seller in respect of each question. A more sophisticated formula is to take the mean of; say, 
the past ten jobs for each seller. An even more sophisticated formula would be to calculate the average price for the past hundred 
25 jobs on a sliding exponential scale where the more recent jobs are weighted more heavily than the earlier jobs. One of the main 
driving factors is to ensure (and make it known to the sellers) mat there is a direct correlation between recent invoicing pattern 
and work awarded 

Table 2 below sets out questions 8-12 which are stored as a question in questions table 1708 of database 1070, which 
form part of the initial request put out by the buyer. Questions 8 and 9 are calculated using a separate software module which 
30 calculates the optimum times and distances between the various investigators and the investigation sites. The travel module takes 
the origin suburb(s) and the destination suburb(s) and return the shortest distance each seller would have to travel as described 
above. 



QB 


How many kilometres will the investigator travel? 


Q9 


How long will the travel take? 


Q10 


How many hours of surveillance would you like conducted? 


QH 


When are the instructions to be received? 



Table 2 - Request Questions 
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Referring now to Figure 5, a table of the mean responses of three sellers in respect of each question is shown. The 
request column 410 in respect of seller one shows, at questions 8-10 respectively, the kilometres the investigator will travel (5), 
the travel time (10), and the respective hours of surveillance requested (20). 

The historical average column 412 provides the historical averages for seller 1 in respect to questions 8-10 as calculated 
5 using the historical calculation formula- In the case of seller 1, the historical average kilometres travelled is given as 17. This is 
calculated by extracting from the units column 404 in Figure 4. The units (in this case kilometres) corresponding to question 14 
and using the historical calculation formula to derive the "average" of 17. Similarly, the average travel time of 31 hours is 
extracted from the database of Figure 4, as is the average investigation time of 20 hours. The respective completion and 
commencement dates are similarly averaged. The average historical cost per unit of surveillance delivered by seller one is shown 
10 at 414. Sorting the data in this historical average fashion makes the calculation of expected surveillance costs quite easy by simply 
multiplying the number of requested surveillance hours (20) by the average historical cost per unit of surveillance (40.85). 

Significant advantages of the system and method of the invention are realised when the groups of similar questions are 
combined into columns using the various formulae such as those set out in Table 3 below. 



CI 


(Q8R*Q14HHQ9R*Q15H)4<Q10R*Q13H)+Q16+Q17+Q18 


C2 


((Q21H*3)-KQ22H*2>HQ23H*1)) 


C3 


Q20H-Q12H 


C4 


l*((Cl/ClAve>l)+((C2/C2Ave)-l)+-l*((C3/C3Ave)-l) 



Table 3 - Algorithms for calculating each of the columns 



1 5 Column 1 indicates the expected cost for each seller for the particular job. The result is displayed as a dollar amount in 

Table 4 below for each seller. According to the formula, the column CI displays the sum of the following five variables or 
combinations thereof- the requested kilometres in question 8 multiplied by the historical average cost per kilometre of question 
14; the requested hours of travel of question 9 multiplied by the historical average cost per hour travelled of question 15; the 
requested hours of investigation of question 10 multiplied by the historical cost per hour of investigation of question 13; and the 

20 historical averages of questions 16-18. 





Seller 1 


Seller 2 


Seller 3 


Average 


Stance 


CI 


$1,064.99 


$1,140.91 


$1,298.87 


$1,168.26 


Goofy 


C2 


60.08% 


67.76% 


76.42% 


68.09% 


Natural 


C3 


26.79 


19.71 


23.98 


23.49 


Goofy 


C4 


-0.17 


0.18 


-0.01 


0 





Table 4 - Column Calculation results 



In column 2, each of the quality-related questions 21-23 is weighted by multiplying the question by a particular 
weighting factor. In the particular example, question 21 is heavily weigjited by being multiplied by three, question 22 is 
moderately weighted by being multiplied by two, and question 21 is not weighted at all, and is thus multiplied by one, with the 
25 result being divided by six and displayed as a percentage. In column 3, the average is requested commencement date is subtracted 
from the average actual completion date of question 20 to get the average job duration in days. 
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When combining separate data types which represent different units, such as cost (currency) quality (percentage) and 
duration (days), each of the values needs to be normalised. Hie direction of normalisation depends on whewer the most F eferred 
value is the higher value, (as in the case of quality) or the lowest value (as is the case with cost). To combine cost and quality, the 
columns need to be normalised in different directions. For illustrative purposes, this is known as "stance". When the best result 
for a column is the highest result (as is quality) this is known as "natural" stance, and when the best results are the lowest, (such 
as costs and duration) this is called left or "goofy" stance (using skating/surfing terminology). 

Column C4 of Table 4 includes a formula which effectively normalises and then combines the respective cost, quality 
and duration factors of columns 1 to 3 to arrive at a figure which quantifies the relative desirability of each seller. In the particular 
calculation, cost, time taken to complete the job and the combination of the above mentioned quality factors have all been given 
equal weightings. Naturally, this can be altered by the buyer simply by using the selected multiplier on each of the normalised 
figures. 

In the particular example, the formula of C4 has the effect of normalising each of the column calculations of C1-C3 
around zero. It will be noted that C4 has been calculated to yield a "natural" result, in which the highest figure indicates the 
preferred seller. This is achieved by using a multiplier of-1 in the case of CI and C3, both of which have a ''goof/' stance. 

Assuming that seller 2 is selected, seller 2 is then notified and commences the job in accordance with the laid down 
parameters. On completion of the job seller 2 submits an invoice in a broken down format as described above which readily 
allows it to be entered into the database 1070. This can be achieved automatically, with manual entry being confined to quality 
questions 21-23. 

Database 1070 can be arranged in many ways, for example, database 1070 may be a relational database having data 
referenced by many variables eg, service elements, and service provider. Alternatively, a series of databases each pertaining to a 
possible service element or service provider may be used. Other configurations are also possible. An exemplary database structure 
which can be used in a system for selecting service providers to investigate insurance claims is shown in Figures 7A to 7E of the 
accompanying drawings. As will be appreciated the database 1070 is a relational database comprising a plurality of interrelated 
tables. Selected tables and the relationships between mem wffl now be described. 

Data relating to each user (or buyer) is stored in accordance with the "users" table 1706, the "users.data" table 1712, 
and the "users details" table 1712. Groups of users are also defined in the "groups" table 1713. Data for each service provider 
includes the d~ata stored in the "seller" table 1701, the "seller.users" table 1702, the "sellers_data" table 1702.1 and the 
"sellers_details" table 1702.2. For example details of each of a sellers employees is stored in the "seller_users" table 1702. 

To generate a job request (create a new transaction) a series of questions from the questions table 1708 are answered by 
the buyer as described above. The answers to the questions define the requested service and are stored as answers in the answers 
table 1707 The "transactions" table 1703 stores data relating to each service request made. Each job or transaction is associated 
with an insurance claim (relationship 1704), an invoice and a user 1706 ie. the buyer who has requested the job. The system uses 
the claim number data stored in the "claims" table 1705 or transaction id stored in the "transactions" table 1703 to identify and 
track a job through the system. Transactions for which a service provider has been appointed has the selected service provider's 
data associated with it 

Invoicing works along the same lines as the creation of a transaction with the selected supplier being asked a number of 
questions 1708 relating to the attributes of the service they provided and cost of the service. The answers to the invoicing 
questions are stored in the answers table 1707, and associated with the transaction id. The answers stored in this way form the 
basis of the invoice. Data for tracking, inter alia, when invoices are generated and payed is stored in the "invoices" table 1709. 
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Quality (and timeliness data) relating to a job are also stored through a question and answer process. The buyer and 
seller are asked a series of questions stored as questions (1708) and their answers 1707 are stored. If quality ratings are requested 
by the buyer when requesting a job, these answers are extracted from the answers table of the database 1070 and used to calculate 
comparable quality data for each service provider. 

As can be seen the database structure provides a set of historical cost and quality data relating to each claim or 
transaction for that is able to be referenced by service provider and used for calculating comparable performance data for each 
service provider for the next job requested. 

The described method is thus implemented using an application which is typically in XML format. The data structure 
for a request is most naturally described using a schema and an XML document Annexure A is a sample XML file showing a 
typical surveillance request Annexure B is a schema which defines the valid request XML file. The contents and operation of this 
schema and the file of Annexure A will be clearly apparent to a normally skilled XML programmer. 

It would be appreciated by a person skilled in the art that numerous variations and/or modifications may be made to the 
present invention as shown in the specific embodiments without departing from the spirit or scope of the invention as broadly 
described. For example, the present selection system for investigation services here described has been implemented on the 
Internet, but other networks configurations could also be used to implement the present invention. The present embodiments are 
therefore, to be considered in all respects to be illustrative and not restrictive. 

Copyright Notice/Permission 

A portion of the disclosure of this patent document, and in particular Annexures A and B, contain material which is 
subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent 
document as it appears in patent office records once publicly available, but otherwise reserves all copyright rights whatsoever. 
The following notice applies to the software and data as described and illustrated below. Copyright 2001, 2002, 2003, River 
Dynamics Pty Ltd., All rights reserved. 
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AnnexureA 

XML file: requestxml 

The data structure for a request is most naturally described with a schema and xml document The following is a sample XML 
file showing a surveillance request 

5 1 .<?xml versions .0" encoding^'UTF-S"^ 

2. <request transactionlcV'l M requestorId="269" xinlns= , Tittp://www.a 

xmlns:xri=*littp://w^ 
xsi:s<&emaI^catiorF=^rtp://ww^^ 

3. requestxsd"> 



10 4. <sellers> 

5. <sellerid= n l"> 

6. <questions> 

7. <module qid="8° type^ travel" retumType= tt distance" calcMethod= n oneToMany" calcOperation= ,, sum rt > 

8. <origins> 
15 9. <origin> 

10. <address> 

11. <street£> 

12. <city>Liverpool</city> 

13. <state>NSW</state> 
20 14. <country>AU<^country> 

15. </address> 

16. </origin> 

17. <origin> 

18. <address> 
25 19. <street/> 

20. <city>Sydney</city> 

21. <state>NSW</state> 

22. <country>AU</country> 

23. </address> 
30 24. </origin> 

25. </origins> 

26. <destmations> 

27. <destination> 

28. <address> 
35 29. <street/> 

30. <city>Bondi</city> 

3l] <state>NSW</state> 

32. <country>AU</country> 

33. </address> 
40 34. </destination> 

35. </destinations> 

36. </module> 

37. <module qid= M 9 w type=="traveI M returnType= n travelTinie" calcMethoc^^oneToMany" 
calcOperatioir="surn^> 

45 38. <origins> 

39. <origin> 

40. <address> 

41. <street/> 

42. <city>Liverpool</city> 
50 43! <state>NSW</state> 

44. <country>AU</country> 

45. </address> 

46. </origin> 

47. <origin> 

55 48. <address> 

49. <street/> 

50. <city>Sydney</city> 
5l] <state>NSW</state> 
52. <country>AU</country> 
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53. </address> 

54. </origin> 

55. </origins> 

56. <destinations> 

5 57, <destination> 

58. <address> 

59. <street/> 

60. <city>Bondi</city> 

61. <state>NSW</state> 
10 62. <country>AU</country> 

63. </address> 

64. </destination> 

65. </destinations> 

66. </module> 

15 67. <q id= M 1 0" type= n number">20</q> 

68 <q id="l 1 w type="dateTime t >2()02-09-20T()0:00:00^ 

69. <*1 id=" 12" type^MateTime ,l >2002.07-20T00:00:0Of 10:0(X/q> 

70. </questions> 

71. </sd\et> 

20 72. <seller ki="2"> 

73 <miestions> „ „ 

74. < m0 dule qid^S" type="travel" returnType="distance M calcMethod^oneToMany" calcOperatio^sum^ 

75. <origins> 

76. <origin> 

25 77. <address> 

78. <streetf> 

79. <city>Peorith</city> 
8o! <state>NSW</state> 
8i, <country>AU</country> 

30 82. </address> 

83. </origin> 

84. <origin> 

85. <address> 

86. <street/> 

3 5 87. <city>Chatswood</city> 

88! <state>NSW</state> 

89. <country>AU</country> 

90. </address> 

91. </origin> 
40 92. </origin£> 

93. <destinations> 

94. <destination> 

95. <address> 

96. <street/> 

45 97, <city>Bondi</city> 

98^ <state>NSW</stat<S> 

99 <country>AU<country> 

100. </address> 

101. </destination> 
50 io2. </destinations> 

103 </module> 

104^ <module qid= ,, 9 M type="travel w rctumType="travelTime" calcMethod^oneToMan/ 

calcOperation== u suni , '> 

105. <origins> 

55 106! <origin> 

107. <address> 

108. <street/> 

j 09. <city>Penrith</city> 

! j 0! <state>NSW</state> 

g0 ill! <country>AU</country> 

112. </address> 

113. </origin> 
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1 14. <origm>' 

U5 <address> 

116! <streetf> 

j j 7 ' <city>Chatswood</city> 

118 ] <state>NSW</state> 

2 j 9 <country>AU</country> 

120. </addres$> 

121. </origin> 

122. </originS> 

123. <destinations> 

124. <destination> 

125. <address> 

\26. <street> 
12 7 <city>Bondi</city> 
l2 % <state>NSW</state> 
129 | <country>AU</country> 
13Q p </address> 

131. </destinatiofl> 

132. </destination$> 

133. </module> 

134 <qid= ,, 10 B type= M number ,, >20</cf> 

1 35 <q id=" 1 1 » type^ , dateTmie^2002-09-20TOO:00:00+10:00</qF> 
136! <q id= M 12 tt type="dateTime^2002-07-20TOO:00:00+10:00</q> 

137. </questions> 

138. </sd\ct> 

139. <seller id="3"> 

IS <qU <Se qid="8« type=«tmvel n retumTypc^'distancc" calcMethod="oneToMany" 

calcOperation= ,l 5um"> 

142. ,<originS> 

143. <origii£> 

144. <address> 

145^ <street/> 
14 ^' <city>Panamatta</city> 
147 * <state>NSW</state> 
14 g' <country>AU</country> 

149. </address> 

150. </origin> 

151. <origiii> 

152. <address> 

<street/> 

<city>Blacktown</city> 
<state>NSW</state> 
[Yfi <country>AU</country> 

157. </address> 

158. </origin> 

159. </origin$> 
150. <destinations> 
j(j 1 . destination?" 

162. <address> 

163. <street/> 

J54* <city>Bondi</city> 
165 ' <state>NSW</state> 
166 ' <countr/>AU</country> 
157! </address> 
153* </destination> 
1^9* </destinationS> 

15?; ^Mtqi^r type= tt travel" retumType-^velTime" calcMethod^oneToMany" 

calcOperation^sum'^ 
172. <origins> 
173 <origin> 



153. 
154. 
155. 
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174, <address> 

175. <street/> 

17$' <city>Parramatta</city> 
177 * <state>NSW</stattf> 
17g' <country>AU</counlry> 

179. </address> 

180. </origin> 

181. <origin^ 



182. 

10 183! <«ieel/> 

1 8 4 <dty>Blacktown</cit^> 
185 ' <state>NSW</state> 
155* <country>AU</country> 
lg 7> </addres£> 

15 188. </origin> 

189. </origins> 

190. <destinations> 



191. 



<destination> 



192. <address> 

20 193* <street/> 

194* <city>Bondi</city> 

195* <state>NSW</state> 

19^* <country>AU</country> 

197, </address> 

25 198. </destinatiori> 

199. </destinations> 

200. </module> 

201 <q id="l 0" type="number">20</q> 

202 ' <q id="l 1" type= ,, datcTime^2002-09-20TOO:00:(KH-10:00</qf> 

30 203^ <q id=="12" type«MatcTtae^>2002^7-20TOO:00:00+10:0()</q> 

204. </questionS> 

205. </seller> 

206. </sellers> 

207. <display> 

35 208. <coliram id= M 1 w returnType^'all'^ 

209. <calc type="sum H > 

210 <calc type^'producf^ , 

21 ! <q id="13 M type- Wency" limiH'10" orderBy= n asc" use="histoncal"/> 

212'. <q id« n 10" type="number" limit= M 10 M orderBy="asc" use=' , requested H > 

40 213. </calc> 

214. <calc type= u product"> , , 

215 < q id^'14" type^currency" lmrit="10 M orderBy= H asc" use= histoncal > 

2i 6 ; <q id="8" type= u number" limit= M 10" orderBy= M asc" use="requested H /> 

217. </calo 

45 218. <calc type= M product"> . 

J 219 <q ^=' , 15 M type^currency" limit= M 10" orderBy= M asc tt useF="histoncal M A> 

220! <q 1*^9" type^'number" liroit^'l 0" orderBy= M asc" use="requested7> 

221 </calO 

222 <q id= M 16" type="currency" limit^'lO" orderBy^asc" use= w historicaT£> 
c a 223 <q id= w 17 M type^currency 1 ' limit="l 0" orderBy= M asc" use=''historical7> 

224*. <qid= M 18 B type="currenc/l^^ 

225. </calo 

226. </columiP > 

227. <column id« M 2 M returnType^all^ 
cc 228 <calc type= =H mean n > 

229 <q id* B 2r type="percentage M liirot= w 10 M orderBy^asc" use= M historicaP/> 

o^O* <n id-"2P type=»percentage M limitF M 10 M orderBy="asc" use="historical V> 

231* <q id="21 M type= u percentage n limit^'lO* orderBy= w asc w use= 4, historical n /> 

232* <q id="22 M type= M percentage" limit^' 1 0" o^ierBy= M asc ,, use== M historicaT£> 

60 £3 <Q id="22 B type^percentage" limit= M 10" orderBy= M asc« us^Tiistorical^ 

OU 234. <q id= M 23 ,, type="percentage" lhnit="10" orderBy="asc" use= M historical"> 

235. </calO 
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236. </cohimn> 

237. <column id="3" returnType^"all"> 

238. <calc type= n minus"> , 

239 <q id="20" type^'dateTime 1 ' limit= n 1 0 M orderBy="asc" use= M histoncal' i> 

5 240. <q Id-^12" type= M dateTime w limit="10 M orderBy= n asc M use= l, historical M /> 

241. </calo 

242. </columri> 

243. <column id s ="4 n retumType="all"> 

244. <calc type="mean"> 

10 245. <c icN w l " type= n norm M stance= n goofy/> 

246^ <c id= M 2 n type="norm n stance= ,l natural"/> 

247. <c id="3 n type== M norm h stance="goofy"/> 

248. </calO 

249. </cohinui> 
15 250. </display> 



251.</request> 
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AnnexureB 

XML Schema: requestxsd 

The following schema defines a valid requestxml file: 

1 .<?xml version-" 1 .0" encomng="UTF-8 M ?> 
5 2.<!~ edited with XML Spy v4.4 U (http://www.xmlspy.com) by doug hudgeon (keen collective) -> 

3. <xs:schema targetNamespace= M http://www.sroa 

xmlns:small~"http://w^ xmlns:xs= N http:/Avww.w3. org/200 1/XMLSchema" 

elementFormDefault="qualified 1 ' attributeFormDefeult= l, unqualified"> 

4. <xs:element name= H request n > 
10 5. <xs:annotation> 

6. <xs:documentation>Request that comes from the front end to the SmartAlloc backend for display of 
sellers</xs:documentation> 

7. </xs:annotation> 

8. <xs:complexType> 

15 9. <xs:complexContem> 

10. <xs:extension base= s * , small:requestType ,, /> 

11. . </xs:complexContent> 
1Z </xs:complexType> 

13. </xs:element> 
20 14. <xs:complexType naine="calcType H > 

15. <xs:sequence minOccurs= n 0 ,l > 

16. <xs:annotation> 

1 7. <xs:documentation>The calculation can be a question in the request (such as 20 hours of surveillance) 
multiplied by the average cost of each seller for each hour of surveillance they conducted in the 

25 past</xs:documentation> 

1 8 . <7xs: annotation> 

19. <xs:element name= n calc f, type="small:caIcType ,t nunOccurs^O" maxOccurs="unbounded7> 

20. <xs:element name»"q" type= ,, small:qType M minOccurs="0 n rriaxCkxurs= n imbounded"> 

21. <xs:annotation> 

30 22. <xs:documentation>Questions can be given additional weighting by including them more than once in 
the column.</xs: documentation 

23. </xs:annotation> 

24. </xs:element> 

25. <xs:element name^umber" minOccurs= ,l 0 n /> 

35 26. <xs:element name="c" minOccurs= w 0 M maxOccurs= M unbounded , *> 

27. <xs:annotation> 

28. <xs:documentation>Columns (previous calculations) can be included in the current 
calculation.</xs:documentation> 

29. </xs:annotation> 
40 30. <xs:complexType> 

3 1 . <xs:attribute name="id" type= ,, xs:integer ,, use= M required"/> 

32. <xs:attribute name="type" use= M required M > 

33. <xs:simpleType> 

34. <xs:restriction base="xs:NMTOKEN 1, > 
45 35. <xs: enumeration vaIue« n norm n /> 

36. </xstrestriction> 

37. </xs:simpleType> 

38. </xs:attribute> 

39. <xs:attribute name="stance" use="required"> 
50 40. <xs:simpleType> 

41. <xs:restriction base= M xs:NMTOKEN"> 

42. <xs:enumeration value^'goofy"^ 

43. <xs:enumeration value="natural"/> 

44. </xs:restriction> 
55 45. </xs:simpleTVpe> 

46. </xs:attribute> 

47. </xs:complexType> 

48. </xs:element> 

49. </xs:sequence> 
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50. <xs:attributc name="type tt > 

51. <xs:simpleType> 

52. <xs:restrictionbase^ M xs:NMTOKEN w > 

53. <xs:enumeration value="pro ductn ^ > 
5 54. <xs:enumeration value^Mivide7> 

55. <xs:enumeration value« M rninus M £> 

56. <xs:enumeration value= M sum ,f A> 

57. <xs:en\imeration value= M mean , '/> 

58. </xs:restriction> 
10 59. </xs:simpleType> 

60. </xs:attribute> 

61. </xs :complexType> 

62. <*s:cornplexType name= M qType n > 

63. <xs:simpleContent> 

15 64. <xs:extension base= H xs:string w > 

65. <xs:attribute name^id" type= ,, xs:integer" use^'required^ 

66. <xs:attribute name="rype n use= tt requiied ,, > 

67. <xs:sunpleType> 

68. <xsn-estriction base="xs:NMTOKENS B > 
20 69. <xs:enumeration value="currency n A> 

70. <Xs: enumeration value= n number l, A> 

71 . <xs:enumeration value= n percentage n /> 

72. <xs:enumeration value^"dateTime"> 

73. </xs:restriction> 
25 74. </xs:simpleType> 

75. </xs:attribute> 

76. <xs:attribute name= M use" use="optional n > 

77. <xs:annotation> 

78 . <xs:documentatic^"Historicar indicates that the historical data should be used in the calculation; 
3 0 "requested" indicates that the requested data should be used.</xs:documentation> 

79. </xs:annotation> 

80. <xs:simpleType> 

81 . ^restriction base="xs:NMTOKENS"> 
g2. <xs: enumeration value= n historical tt A> 

35 83. <xs:enumeration value= M requested"/^ 

84. </xs:restriction> 

85. ^xs:simpleType> 

86. </xs:attribute> 

87. <xs:attribute name^lmrit" type="xs:string M use="optional M /> 
40 88. <xs:attribute name="orderBy n use="optional ,l > 

89. <xs:simpleType> 

90. ^.restriction base="xs:NMTOKENS ,, > 

91. <xs: enumeration value="asc M /> 

92. <xs: enumeration value="desc"/^ 
45 93. </xs;restriction> 

94.. </xs:simpleType> 

95. </xs:attribute> 

96. </xs:extension> 

97. </xs:simpleContent> 
50 98. </xs:complexType> 

99. <xs:complexType narne="requestType"> 

100. <xs:sequence> 

101. <xs:annotation> 

102. <xs:documentation>Each request has two components - Sellers and Display</xs:documentation> 
55 103. </xs:annotation> 

1 04. <xs:element name= ,, sellers n typ^smallisellersType^ 

105. <xs:annotation> 

1 06. <xs:documentation>Sellers includes all of the information needed to return a result for each seller 
you may choose to perform work.</xs;documentation> 

60 107. </xs:annotation> 

108. </xs:element> 

1 09. <xs:element name^'display" rype="small:displayType M > 
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110. <scs:annotation> " ... . 

1U <xs:documentation>Display lists the comparison criteria for the sellers. For example, quality or cost 

or duration, or a combination of all three.</xs:documentation> 

112. <xs:annotation> 

5 113. </xs:element> 

114. </xs:sequence> 

1 15. <xs:attribute name= M transacuonId" type="xs:integer H use^'required"^ 

116. <xs:attnTMitename= w requesto^ 

117. </xs:complexType> 

10 118. <^:cornplexTypename== M displayType H > 

119. <xs:sequence> 

120. <xs:element name="column" maxOccurs= M unbounded M > 

121. <xs:annotation> 

122. <xs:documentation>Each criteria is displayed in a column. Each row in the column corresponds to a 
15 seller.</xs:doaimentation> 

123. </xs:annotation> 

124. <xs:complexType> 

125. <Xs:sequence> 

126. <xs:element name="calc" type^smalhcalcType'^ 
20 127. <xs:annotation> 

1 2 g <xs:documentation>Define the calculation for the column.<xs:documentation> 

129. </xs:annotation> 

130. </xs:element> 

131. </xs:sequence> 

25 132. <xs:attribute name="id" type^xsunteger" use="required7> 

133. <xs:attribute name^"returnType M use*"required"> 

134. <xs:simpleType> 

135. <xs:restriction base= n xs:NMTOKEN"> 

136. <xs:enumeration value= w highest ,, /> 
30 137. <xs:enumerationvalue="lowest M £> 

138. <xs:enumeration value="air/> 

139. </xs:restriction> 

140. </xs:simple'IVpe> 

141. </xs:attribute> 
35 142. </xs:complexType> 

143. </xs:element> 

144. </xs:sequence> 

145. </xs:complexType> 

146. <xs:complexType name="sellersType H > 
40 147. <xs:sequence> 

148. <xs:element name^'seller" maxOccurs s = ,, unbounded w > 

149. <xs:annotation> 

1 50. <xs:documentation>List each seller you want to return results for</xs:documentation> 

151. </xs:annotation> 
45 152. <xs:complexType> 

153. <xs:sequence> 

1 54. <xs:element name^'questions^ 

155. <xs:annotation> 

1 ^ <xs:documentation>Questions are the criteria you want to assess the sellers on. For 
50 example, a question could be "Hours of Surveillance requested". This requests results for each seller based on the a 
specific number of hours of surveillance.</xs:documentation> 

157. <xs:annotation> 

158. <xs:complexType> 

159 <xs:sequence> 

55 J 6Q [ <xs:element name="module" type= ,, small:moduleType ,t rnmOccurs=="0'' 

maxOccurs= n unbounded"> 

i 6 l <xs:annotation> 

j 02 <xs:documentation>SmartAlloc has some special 
modules, such as the travel module. The travel module takes origin suburb(s) and destination suburb(s) and returns the 
60 shortest distance each seller would have to travel.</xs:documentation> 

1 63 </xs:annotation> 

164. </xs:element> 
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<xs:element name="q" minOccurs="0" maxOccurs="unbounded"> 



c 



i <xs: annotation> 

j 67 ' <xs:documentation>For standard questions (number of 

hours of surveillance) a straight mathematical calculation can be o)nducted.</xs:documentation> 

5 16g </xs:annotation> 

159 <xs:complexType> 

i 70 * <xs:simpleContent> 

171 ' <xs:extension base="small:qType"/> 

172 [ </xs:simpleContentP> 

173 ] </xs:complexType> 

174 # ^xsielement?* 

175 </xs:sequence> 

176. </xs;complexType> 

177. </xs:element> 
15 178. </xs:sequence> 

179. <xs:attribute name= n id M type=="xs:integer" use= ,, required"A> 

180. </xs:complexType> 

181. </xs:element> 

182. </xs:sequence> 
20 183. </xs:complexType> 

1 84. <xs:complexType name= ,, addressType t, > 

185. <xs:sequence> 

1 86. <xs:element name-'street"/^ 

187. <xs: element name^city"^ 
25 1 88. <xs:element name^state"/^ 

189. <xs:element narae= n country"/> 

190. </xs:sequence> 

191. </xs:complexTvpe> 

1 92. <Xs:complexType name="moduleType I *> 

30 193. <xs:sequence> 

1 94. <xs:element name= 5,, origins tt > 

195. <xs:armotation> 

19 6 . <xs:documentation>The list of charge-out points for each seller. This data will commonly be received 
from a separate call to a SOAP server that lists the charge-out points of each of seller listed in your 

35 request</xs:documentation> 

197. <Vxs:annotation> 

198. <xs:complexType> 

199. <xs:sequence> 

200. <xs:element narne« M origin , ' maxOccurs= n unbounded ,, > 
40 20 1 . <xs:complexType> 

202. <xs:sequence> 

203] ocszelement name= j,, address M type= fh small:addressType M /i> 

204. </xs:sequence> 

205. </xs:complexType> 
45 206. </xs:element> 

207. </xs:sequence> 

208. </xs;complexType> 

209. </xs:element> 

210. <xs:element name= n destinations n > 
50 211. <xs:annotation> 

212. <xs:documentation>List of locations that the work will be conducted in.</xs:documentation> 

213. <xs:annotation> 

214. <xs:complexType> 
215 <xs:sequence> 

55 2I6. <xs:elerrCTtr^=Mestination w nmOccurs= M unbounded n > 

217. <xs:complexType> 

218 <xs:sequence> 

219] <xs:element name= M address" type="small:addressType ,, /> 

220. </xs:sequence> 

60 221 ! <^xs:complexType> 

222, </xs:element> 

223. </xs:sequence> 
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224. </xs:coinplexType> 

225. </xs:element> 

226. ^/xs:sequence> . 

227. <xs:attribute name= M qid H type="xs:integer" use= M required > 
5 228. <xs:atmT>utenanie=' ,, type ,, use s = w required ,, > 

229. <xs:simpleType> 

230. <xs:restrictionbase= H xs:NMTOKENS H > 
23 \[ <xs:enumeration value ss "traverA> 
232. </xs:restriction> 

10 233. </xs:simpleType> 

234. </xs:attribute> 

235 . <xs:attribute nameF="calcMethod w use= ,, required"> 

236. <xs:simpleType> 

237. <xs:restriction base^'xsiNMTOKENS'^ 
12 238^ <xs:enumeration valu^oneToMany"/^ 

239. </xs:restriction> 

240. </xs:simpleType> 

241. </xs:attribute> 

242. <xs:attributc naroe^calcOperation" use* M required"> 
20 243. <xs:simpleType> 

244. <xs:restriction base= M xs:NMTOKENS "> 

245* <xs:enumeration value^'sum*^ 

246. </xs:restrictiori> 

247. </xs:simpleType> 
25 248. </xs:attribute> 

249. <xs:attribute name= M ^etu^lType ,, use^"required M > 

250. <xs:simpleType> 

25 1 . <xs:restriction base^ n xs:NMTOKENS"> 

252. <xs:enumeration value= rt distanced 
30 25 3 . <xs: enumeration value="travelTime7> 

254. </xs:restriction> 

255. </xs:simpleType> 

256. </xs:attribute> 

257. </xs:complexType> 
35 i </xs:schema> 
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Claims 

1. A computerised method of enabling a buyer to select a service provider for performing a service; said method 
including: 

(a) processing a service enquiry for a particular service; 

5 (b) retrieving historical cost data associated with said service in respect of a plurality of service providers in response to 

said service enquiry; 

(c) processing said historical cost data to arrive at comparable cost data in respect of said plurality of service providers for 
enabling the selection of a service provider to perform the particular service; 

(d) capturing cost data relating to the provision of the particular service by the selected service provider, and 
10 (e) updatfag me historical cost data 

2. A computerised method as claimed in claim 1 which includes repeating steps (a) to (e) to enable a buyer to select 
a service provider for the provision of subsequent services with the aid of regularly updated historical cost data. 

3. A computerised method as claimed in either claim 1 or claim 2 which includes compiling an historical cost 
dataset including historical cost data components associated with the provision of at least one similar previous service by each 

15 service provider. 

4. A computerised method as claimed in any one of the preceding claims wherein the service enquiry includes a 
plurality of service components and the historical cost data includes historical cost data for a plurality of comparable service 
components, and step (c) includes: 

processing said historical cost data to arrive at cost data for each of said service components. 

20 5. A computerised method as claimed m any one of the preceding claims wherein the cost data captured in step (d) 

includes cost data for each of the service components included in the service enquiry. 

6. A computerised method as claimed in claim 5 in which the service components include cost per unit of time 
and/or distance, in combination together with units of time and/or distance. 

7. A computerised method as claimed in any one of the preceding claims which includes the additional steps of: 

25 (f) retrieving historical quality data associated with said service in respect of a plurality of service providers in response to 

said enquiry, and 

(g) processing said historical quality data to arrive at comparable quality data in respect of said service providers to enable 
the selection of a service provider to perform the particular service. 

8. A computerised method as claimed in claim 7 which includes the additional steps of. 

30 (h) capturing quality data relating to the provision of the particular service by the selected service provider; and 

(i) updating the historical quality data to incorporate said captured quality data. 

9. A computerised method as claimed in claim 8 which includes: 

Repeating steps (f) to (i) to assist a buyer to select a service provider for the provision of subsequent services with the aid 
of regularly updated quality data. 
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10. A computerised method as claimed in any one of the preceding claims which includes: 

compiling an historical quality dataset including historical quality data associated with the provision of at least one 
previous service by each service provider. 

11. A computerised method as claimed in any one of claims 7 to 10 wherein the historical quality data includes 
5 historical quality data for a plurality of performance attributes, and the service request enquiry includes a plurality of comparable 

performance attribute weightings reflecting the relative importance of at least two of the performance attributes to tiie buyer. 

12. A computerised method as claimed in claim 7 wherein step (g) includes: 

processing said historical quality data in respect of each of the performance attributes to arrive at comparable performance 
data in respect of each performance attribute, and combining said comparable performance data according to r^fbrmance attribute 
10 weightings contained in the service enquiry for each service provider, to generate said comparable quality data. 

13. A computerised method as claimed in any one of claims 7 to 12 which includes quantifying the quality data 
relating to selected performance attributes using any derived scale, weighting such performance attributes according to their relative 
importance, normalising the data relating to one or more of said selected performance attributes and combining them with the 
similarly normalised historical cost data relating to other selected performance attributes, in combination with an additional 

15 weighting factor. 

14. A computerised method as claimed in any one of claims 7 to 13 wherein the comparable cost data and 
comparable quality data in respect of each of the service providers is combined to derive a comparable performance index for each 
service provider for enabling the selection of a service provider to perform the particular service, with the combination of the 
comparable cost data and comparable quality data being arranged m accordance with weightings reflecting the relative importance of 

20 the comparable cost data and comparable quality data to the buyer. 

15. A computerised method according to any one of the preceding claims wherein the historical cost data includes 
corresponding historical service enquiry data, wherein the step of processing said historical cost data includes processing said related 
service enquiry data to arrive at comparable cost data. 

16. A computerised method according to any one of the preceding claims which includes the steps of capturing 
25 service enquiry data associated with the captured cost data, and updating the historical cost data by incorporating said captured 

service enquiry data. 

17. A computerised method of enabling a buyer to select a service provider for performing a service, said method 

including: 

(a) compiling historical cost and quality datasets including historical cost and quality data associated with the provision of 
30 at least one previous service by each service provider. 

(b) receiving and processing a service enquiry from the buyer for a particular service; 

(c) retrieving historical cost and quality data associated with said service in respect of a plurality of service providers in 
response to said enquiry; and 

(d) processing said historical cost and quality data to arrive at comparable cost and quality data in respect of said service 
35 providers for enabling the selection of a service provider to perform the particular service. 

18. A computerised method as claimed in claim 17 which includes: 
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(e) capturing cost and quality data relating to the provision of the particular service by the selected service provider, 

(f) updating the historical cost and quality data to incorporate said captured cost and quality data, and repeating steps (b) to 
(f) to enable a buyer to select a service provider for the provision of subsequent services. 

19. A computerised method as claimed in either one of claims 17 or 18 which includes formatting the service enquiry 
into a plurality of service components, and formatting the historical cost and quality data into a plurality of comparable service 
components, with step (d) including: 

processing said historical cost and quality data to arrive at cost and quality data for each of said components. 

20. A computer-readable medium having stored thereon executable instructions for causing a computer to perform a 
method of any one of the preceding claims 1 to 19. 

21. A computer operating under the control of the computer readable medium of claim 18. 

22. A computer system to enable a buyer to select a service provider for performing a service, said system including: 
, enquiry processing device configured to receive and process a service enquiry for a particular service from me buyer ; 

t database configured to store historical cost data associated with said service in respect of a plurality of service providers; 
, processor carrying instructions to retrieve and process said historical cost data from said database in response to said 
query to arrive at comparable cost data in respect of said service providers for enabling the buyer to select a service provider, on the 
basis of said comparable cost data, to perform the particular service. 

23. A computer system as claimed in claim 20 which includes: 

a data capture component configured to capture cost data relating to the provision of me particular service by the selected 
service provider, and updating means to update the historical cost data on the database with said captured cost data. 

24. A computer system as claimed in either one of claims 22 or 23 in which the system further includes: 

a data compilation component configured to compile a dataset including historical cost and quality data associated with the 
provision of at least one previous service by each service provider. 

25. A computer system as claimed in any one of claims 22 to 24 wherein the enquiry processing device is configured 
to additionally retrieve historical quality data associated with said service in respect of a plurality of service providers in response to 
said enquiry, and the enquiry processing device is configured to generate comparable quality data from said historical quality data in 
respect of said service providers. 

26. A computer system as claimed in claim 25 wherein the historical quality data includes historical quality data for a 
plurality of performance attributes, and the service request enquiry includes a plurality of comparable performance attribute 
weightings reflecting the importance of each of the performance attributes to the buyer. 

27. A computer system as claimed in claim 26 wherein the processor is configured to process said historical quality 
data in respect of each of the performance attributes to arrive at comparable performance data in respect of each performance 
attribute, and to combine the comparable performance data according to the performance attribute weightings included in the service 
enquiry for each service provider, to generate said comparable quality data. 

28 A computer system as claimed in any one of claims 25 to 27 wherein the processor is configured to derive a 
comparable performance index for each service provider by combining the comparable cost data and comparable quality data in 
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respect of each of the service providers with the combination of the comparable cost data and comparable quality data being is 
performed in accordance with weightings reflecting the relative importance of the comparable cost data and comparable quality data 
to the buyer. 

29. A computer system to enable a buyer to select a service provider for performing a service; said system including: 
a database configured to store a first dataset including a plurality of service providers, a plurality of associated services and 

a plurality of associated historical costs; 

a processor in communication with said database, wherein said processor is configured to receive historical cost data 
associated with each service provider and to generate comparative cost data for each service provider according to a predetermined 
algorithm; and 

a communication device configured to communicate said comparative cost data to said buyer to enable the buyer to select a 
service provider. 

30. A computer system as claimed in claim 29 wherein the predetermined algorithm includes weighting means 
configured to weight a plurality of received historical cost data according to the respective associated service of the historical cost 
data, and to generate the comparative cost data in accordance with said weighting. 

31. A computer system as claimed in claim 30 wherein said processor includes weighting optimisation means 
adapted to optimise the weightings applied by the weighting means to the received historical cost data, with the weighting 
optimisation means utilising an algorithm which has the effect of weighting the most recent data more heavily. 

32. A computer system as claimed in any one of claims 29 to 31 which further includes data. capture means 
configured to capture cost data associated with a current service provided by a service provider, and updating means adapted to 
update said first data set to include said cost data associated with the current service provided by a service provider. 

33. A computer system as claimed in any one of claims 29 to 32 wherein the historical cost data includes a plurality 
of associated service components and associated historical cost component data; and the processor is configured to generate 
comparative cost data in respect of each service component for each service provider. 

34. A computer system as claimed in any one of claims 27 to 31 wherein the data storage means is configured to 
store a second dataset including a plurality of service providers, a plurality of associated services and a plurality of associated 
historical quality data, and said processor means is configured to additionally receive historical quality data associated with each 
service provider and generate comparative quality data for each service provider according to a predetermined algorithm; and said 
communication means is arranged to communicate said comparative quality data to the buyer to enable the buyer to select a service 
provider. 

35. A computer system as claimed in any one of claims 22 to 34 wherein the database is configured to store historical 
service enquiry data associated with the historical cost data, and wherein the processor executes instructions to retrieve and process 
said historical cost data in conjunction with said related service enquiry data to arrive at said comparable cost data. 

36. A computer system as claimed in either one of claims 23 or 32 wherein the data capture component is configured 
to capture service enquiry data associated with the captured cost data, with the updating means being arranged to update the 
historical cost data on the database with said captured cost and service enquiry data. 

37. A computer system to enable a buyer to select a service provider for perforniing a service including a database 
substantially as depicted in figures 7A to 7E of the accompanying drawings. 
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